I would recommend reviewing commit-by-commit as there was a lot of moving files around, so a lot of the commits are just "cleaning up" kind of things, that clutter the global diff.

Prior to this PR, the UI for selecting each field of a post was specific to a blog post. This meant that, if we introduced a new type of post (e.g. Product), we would need to implement the UI for selecting the sections of a Product from scratch.

However, the pattern of that UI would be exactly the same for all kinds of posts: user chooses which field they want to select, they click on the field, and then its value is saved in wordpress, and playground gets refreshed.

This PR makes it so that the UI for selecting the fields of a post is generic and will automatically work for any kind of post, without any changes. If however we want to customize the UI for specific posts, we will still be able to do that.

I think this will vastly reduce the time it takes us to add support for new post types, because there is no UI code that needs to be written per post type.

The UI changes here emerge out of changes to the data model, that was made generic, so that it can support multiple post types. More information on this below.

From the user's perspective, the UI hasn't changed, it's exactly the same as prior to this PR.

Why I'm doing this now

I'm doing this now instead of when we will need to add support for other post types because I already encountered challenges that this PR addresses, when trying to add the feature of saving the CSS selectors, because of limitations in the data model.

I think it's important to get the data model right as early as possible, so that we can build on top of a strong foundation.

Data model

The data model now works as follows.

There's a generic Post with the following properties:

type: Type;
id: number;
guid: string;
url: string;
fields: Fields;

Type is the post type, e.g. liberated_post. Fields is an object of fields, e.g.:

{
    date: DateField;
    title: TextField,
    content: HtmlField,
}

Different post types have different fields, BlogPost has the fields from the example above, but a ProductPost would have title, description and price, for example.

Here's the full code for defining the BlogPost type:

type BlogPostFields = {
	date: DateField;
	title: TextField;
	content: HtmlField;
};

export interface BlogPost
	extends GenericPost< PostType.BlogPost, BlogPostFields > {}

Next steps

In the next PR I will implement saving the CSS selectors of the elements the user clicked, which will be easier to do due to the improved data model.